CS 5010: Problem Set 10

Out: Monday, March 28, 2016

Due: Monday, April 4, 2016 at 5pm local time.

Correction: Tuesday, March 29, 2016
(corrected two occurrences of "RETURNS:" to "EFFECT:")

In this problem set, you will re-factor your solution to Problem Set 09 to obtain a similar program that uses objects with mutable state. That should give you some appreciation for both the advantages and disadvantages of mutable state.

Please restrict yourself to the language features discussed in class. The contracts require you to use mutable state for some objects. You will use single inheritance for interfaces, but you are still not allowed to use inheritance for classes. You are still forbidden to define any methods that aren't listed by one of the interfaces your class implements, but your classes are allowed to implement multiple interfaces (so any methods you need can be listed by some interface you invent yourself).

In most other respects, the deliverables and instructions for this problem set are the same as for Problem Set 09. As always, you must follow the design recipe, in this case the OO Design Recipe and deliverables as spelled out in Lesson 9.5 and in deliverables.html. Be sure to sync your work and fill out a Work Session Report at the end of every work session. Use the Work Session Report for PS10.

Starting with this problem set, you will submit your solution in multiple files. Here are the rules:

You are given a StatefulWorld.rkt file that defines several interfaces you are required to use. You are allowed to modify the MyStatefulWorld<%> and MyWidget<%> interfaces of that file. You are not allowed to modify any other interfaces in that file.
All of the files for both questions must live in the same set10 directory, as usual.
Your directory must also include a copy of extras.rkt along with your (possibly modified) copy of StatefulWorld.rkt .
Your simulator-2.rkt file must require the extras.rkt and StatefulWorld.rkt files, and must provide all of the functions and interfaces you are required to provide. Running the simulator-2.rkt file should run all of your tests.
You may organize your other files in any way that is coherent. You should be prepared to defend your organization at codewalk. We recommend putting each of the classes you define in a separate file.

Please read the second problem statement before you begin work on the first problem.

(simulator-2)
The prospective client didn't realize object-oriented programs could be functional instead of stateful, and the prospect of using functional programming techniques seems to make the client uncomfortable. The client therefore insists you re-factor your simulator as a stateful object-oriented program using the interfaces defined in StatefulWorld.rkt . Those interfaces are repeated here for ease of reference.

Please notice that most of the method contracts and purpose statements have changed from Problem Set 09.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;
;;; Interfaces for Problem Set 10
;;;
;;; You are not allowed to modify any of these interfaces
;;; except for MyStatefulWorld<%> and MyWidget<%>.
;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(define StatefulWorld<%>
  (interface ()

    ;; -> Void
    ;; GIVEN: no arguments
    ;; EFFECT: updates this world to its state at the next tick

    after-tick

    ;; Integer Integer MouseEvent -> Void
    ;; GIVEN: a location and what kind of mouse event
    ;; EFFECT: updates this world to its state following the given mouse
    ;;     event at the given location

    after-mouse-event

    ;; KeyEvent -> Void
    ;; GIVEN: a key event
    ;; EFFECT: updates this world to its state following the given key event

    after-key-event

    ;; -> Scene
    ;; GIVEN: no arguments
    ;; RETURNS: a scene that depicts the world

    to-scene
    
    ))

(define StatefulWidget<%>
  (interface ()
    
    ;; -> Void
    ;; GIVEN: no arguments
    ;; EFFECT: updates this widget to its state following a tick
    ;;     while the world is not paused
    
    after-tick

    ;; -> Void
    ;; GIVEN: no arguments
    ;; EFFECT: updates this widget to its state following a tick
    ;;     in which the world is paused

    after-tick-while-paused

    ;; Integer Integer -> Void
    ;; GIVEN: x and y coordinates for a location
    ;; EFFECT: updates this widget to its state following the specified
    ;;     mouse event at the given location

    after-button-down
    after-button-up
    after-drag

    ;; KeyEvent -> Void
    ;; GIVEN: a key event
    ;; EFFECT: updates this widget to its state following the
    ;;     given key event

    after-key-event

    ;; Scene -> Scene
    ;; GIVEN: a scene
    ;; RETURNS: a scene like the given one but with this widget painted on it

    add-to-scene
    
    ))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;
;;; You are allowed to add methods to these two interfaces.
;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(define MyStatefulWorld<%>
  (interface (StatefulWorld<%>)

    ;; you may list additional methods here

    ))

(define MyStatefulWidget<%>
  (interface (StatefulWidget<%>)

    ;; you may list additional methods here

    ))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;
;;; You are not allowed to modify these interfaces.
;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(define SimulatorState<%>
  (interface (MyStatefulWorld<%>)

    ;; -> Integer
    ;; RETURN: the x and y coordinates of the launcher
    launcher-x
    launcher-y

    ;; -> ListOfGoofball<%>
    goofballs

    ;; -> ListOfRobot<%>
    robots

))

(define StatefulWidgetWithLocationAndVelocity<%>
  (interface (MyStatefulWidget<%>)

    ;; -> Int
    ;; RETURNS: the x or y position of the center of this robot
    get-x
    get-y

    ;; -> Int
    ;; RETURNS: the vx or vy component of this robot's velocity
    get-vx
    get-vy

    ))

(define Goofball<%>
  (interface (StatefulWidgetWithLocationAndVelocity<%>)
    
    ;; -> Boolean
    ;; RETURNS: true iff this goofball has the stealth of a Stealth Goofball
    stealthy?

    ))

(define Robot<%>
  (interface (StatefulWidgetWithLocationAndVelocity<%>)

    ;; -> Boolean
    ;; RETURNS: true iff this robot has a SAGR's abilities
    smart?

    ))

Your simulator-2.rkt file must provide the SimulatorState<%>, Goofball<%>, and Robot<%> interfaces. Your simulator-2.rkt file must also provide the following ten functions:

;;; make-world : ListOfGoofball<%> ListOfRobot<%> -> SimulatorState<%>
;;; GIVEN: a list of Goofball<%> and a list of Robot<%>
;;; RETURNS: a world with those goofballs and robots
;;;     and the launcher at its standard initial position

;;; world-after-tick : SimulatorState<%> -> SimulatorState<%>
;;; GIVEN: a SimulatorState<%>
;;; WHERE: the SimulatorState<%> was returned by one of these provided functions
;;; RETURNS: the SimulatorState<%> that should follow the given SimulatorState<%>
;;; EFFECT: this function may change the state of its argument,
;;;     but is not required to do so

;;; world-after-key-event : SimulatorState<%> KeyEvent -> SimulatorState<%>
;;; GIVEN: a SimulatorState<%> and a KeyEvent
;;; WHERE: the SimulatorState<%> was returned by one of these provided functions
;;; RETURNS: the SimulatorState<%> that should follow the given SimulatorState<%>
;;;     after the given KeyEvent
;;; EFFECT: this function may change the state of its first argument,
;;;     but is not required to do so

;;; world-after-mouse-event : SimulatorState<%> Int Int MouseEvent -> SimulatorState<%>
;;; GIVEN: A SimulatorState<%>, the x- and y-coordinates of a mouse event,
;;;     and the mouse event
;;; WHERE: the SimulatorState<%> was returned by one of these provided functions
;;; RETURNS: the SimulatorState<%> that should follow the given SimulatorState<%>
;;;     after the given mouse event
;;; EFFECT: this function may change the state of its first argument,
;;;     but is not required to do so

;;; run-world : PosNum SimulatorState<%> -> SimulatorState<%>
;;; GIVEN: a frame rate (in seconds/tick) and a SimulatorState<%>
;;; WHERE: the SimulatorState<%> was returned by one of these provided functions
;;; RETURNS: the final state of the world after running the given world
;;; EFFECT: this function may change the state of its second argument,
;;;     but is not required to do so

;;; run : PosNum -> SimulatorState<%> 
;;; GIVEN: a frame rate (in seconds/tick)
;;; RETURNS: the final state of the world after starting and running
;;;     the standard initial world

;;; make-stealth-goofball : Integer Integer Integer Integer -> Goofball<%>
;;; GIVEN: x and y coordinates and velocity components vx and vy
;;; RETURNS: A Stealth Goofball with its center at the x and y coordinates
;;;     and velocity components vx and vy

;;; make-round-goofball : Integer Integer Integer Integer -> Goofball<%>
;;; GIVEN: x and y coordinates and velocity components vx and vy
;;; RETURNS: A Round Goofball with its center at the x and y coordinates
;;;     and velocity components vx and vy

;;; make-DAGR : Integer Integer Integer Integer -> Robot<%>
;;; GIVEN: x and y coordinates and velocity components vx and vy
;;; RETURNS: A DAGR with its center at the x and y coordinates
;;;     and velocity components vx and vy

;;; make-SAGR : Integer Integer Integer Integer -> Robot<%>
;;; GIVEN: x and y coordinates and velocity components vx and vy
;;; RETURNS: A DAGR with its center at the x and y coordinates
;;;     and velocity components vx and vy

Be sure to include the extras.rkt and your possibly modified version of the StatefulWorld.rkt files in your set10 directory along with your simulator-2.rkt file and any other files it needs.

(implementation-notes)
As you convert your program into the stateful object-oriented form demanded by the client, take note of any significant difficulties you run into and record them in a plain text file named implementation-notes.txt .
When you are done, add a few paragraphs to that file explaining how your stateful program is better and/or worse than the program you wrote for Problem Set 09. Be prepared to discuss these matters during your code walk.

Last modified: Tue Mar 29 2016